1. Field of the Invention
The invention relates generally to the field of software programs. In particular, the invention relates to a system and method for executing a component of a program.
2. Background of the Invention
There are several methods and systems used to execute programs in both the client-server and stand alone environments. All have several shortcomings, such as platform dependence problems, burdening the server and the network bandwidth, garbage collection, fault tolerances, slow execution speed and other problems.
In some client/server environments, a client is designed to be small so that most of the data processing takes place on the server. These clients are typically referred to as thin clients, and they are advocated by organizations such as Netscape and Sun Microsystems who support Java-based thin clients running on network computers. On the other hand, Microsoft and Intel are pushing larger applications that are run locally on desktop computers.
Software programs are typically developed using one of many high-level languages such as C, Java, C#, VB, Perl, and the like. The source code is compiled into machine code, which the processor can understand and use to execute a program. Generally, programs are compiled and executed using three different methods. High-level language is compiled into machine code by either compiling the program into: (a) a platform dependent executable (‘exe’) or a dynamic link library (‘dlll’); (b) a platform independent byte code that is executed by a virtual machine; or, (c) is interpreted and executed line by line.
The choice of which high-level language and method of program execution to utilize while preparing a software program depends on many factors, such as the ease of development, component reusability, ease of maintenance (which pertains to platform dependence) and faster program execution with minimum resources (which implicate memory and network bandwidth burdens). The scripting language and byte code options are typically used for ease of program maintenance (operating system and processor independence) rather than speed of execution.
Programs written in the C/C++ language form a machine-readable, platform dependent executable when compiled. In the client-server environment, when a user at the client desires to execute a program, the client sends a request to the server and the entire executable is transferred to the client, i.e., a copy of the executable is transferred from a server to the client and executed on the client computer. This involves the use of substantial network bandwidth for sending information back and forth between the client and the server computer. Although most of the processing is done at the client computer, the information required needs to be sent on an ongoing basis.
Another shortcoming is the platform dependence of the program. A program compiled for a Windows operating system cannot be executed on a Linux operating system and vice-y-versa. As a result, the server maintains multiple versions of the executable to service clients running different operating systems.
Sun created Java to address several of these shortcomings. Programs written in Java are platform independent. The Java compiler converts the Java source code to byte code, which is understood by the Java Virtual Machine (JVM). The JVM is platform dependent and translates the program to machine-readable form for execution. The byte code, however, is dense and must be transmitted from the server to the client, thus causing network bandwidth clutter. Further, most of the programs written in Java are programmed such that the processing required is performed at the server computer. This limits the number of clients that can be serviced by the server at one time.
JavaScript and other similar languages are interpreted languages. In such languages, there is an interpreter at the client and the client receives the script in text form. The interpreter at the client interprets one or more lines at a time to execute the program. Because the actual text of the program script is sent, less network bandwidth is burdened than is burdened when C/C++ executables or Java byte code is sent. One reason why less bandwidth is burdened is because the executable and byte code files are denser. JavaScript programs, however, require the entire script to be sent from the server to the client. This unnecessarily clogs up network bandwidth because, in many cases, the entire script need not be transmitted.
In databases used in the client-server environment, such as SQL and Oracle databases, the client sends queries to the server, which sends the requested information to the client. The intelligence required to display the information resides at the client and, hence, some processing relating to user interfaces is performed at the client computer. If expressions need to be solved, however, the server needs to be contacted. In such cases, the server retrieves the information from the database, calculates the result of the expression and sends back the information to the client. This requires the server processor to calculate the result and, thus, slows down and limits the other clients being serviced at the server.
When servers need to undergo regular maintenance procedures, crash or malfunction, the clients are disconnected and can only access the server once the server has been fixed. This problem particularly affects small companies because smaller companies cannot afford multiple servers to transfer client load while malfunctioning server computers are being fixed.
Garbage collection is another problem in the industry in standalone as well as client-server environments. Memory allocated in the Random Access Memory (RAM) needs to de-allocated after use to avoid cluttering the memory. When programs are written in the C/C++ language, programmers must manually deallocate the memory. Programmers use a “malloc” command to allocate space and a de-allocate command to free space. Programmers, however, often times neglect to deallocate memory space when writing software programs, resulting in memory clutter.
Java attempted to address this problem in its JVM. The JVM keeps track of memory that has not been referenced over a period of time and automatically de-allocates that memory. The device with the JVM, however, must incorporate precious processing power to constantly search for and delete the non-referenced objects. Further, the non-referenced objects use up precious memory while not in use and stored in the memory.
There remains a need to address the problems associated with executing programs, such as, network bandwidth and server processing burdens, platform independence, garbage collection, fault tolerances as well as others.